1. Field of the Invention
This invention relates to computer implemented policies in general, and more specifically to automated matching of policy constraints.
2. Description of the Related Art
A major development in the software industry is “web services.” In general, web services are services offered via the Web. Web services can be considered loosely coupled components, or other programmable application logic, that communicate using standard, platform-independent and language-independent protocols. Web services combine aspects of component-based development with Internet protocols. Like components, web services represent black-box functionality that can be used (and reused) without worrying about how the particular service is implemented. Unlike current component technologies however, web services are not normally accessed via object-model-specific protocols, such as DCOM, RMI, or IIOP. Instead, web services are generally accessed via Internet protocols and data formats, such as HTTP and XML.
Web services may be self-contained, self-describing, modular services that can be published, located, and invoked across the Internet. Web services perform functions, which can be anything from simple requests to complicated business processes. In other words, web services are interoperable building blocks for constructing applications. For example, a distributed digital library infrastructure may be built using web services to provide functionality such as distributed search, authentication, inter-library loan requests, document translation and payment. These web services could be combined by a particular digital library service to offer an environment for reaching information resources tailored to a particular user community. Where current Internet protocols enable users to connect to applications, web services enable applications to connect to other applications.
For instance, FIG. 1 is a block diagram illustrating web services consumers and providers of communicating over a network, such as the Internet, via various web services interfaces. Thus, web services consumers 110A, 110B, and 110C may communicate with web services providers 120A, 120B, and 120C via web services interfaces 130A, 130B, 130C, 130D, 130E, and 130F, respectively. For example, web services provider 120A may provide digital library services as described above and may expose those services via web services interface 140A. Web services consumer 110A may implement web services interface 130A to communicate with web services provider 120A. Thus, pairs of web services interfaces may communicate according to compatible protocols.
Additionally, Web services components may link to other web service components to provide a collaborative service. Traditional web services implementations cannot automate this linkage because they generally do not provide a means for components to express their collaboration and communication requirements and offerings in a form amenable to automated processing; nor do they provide a means of matching requirements of one component against the offerings of other components. Examples of requirements and offerings are whether encryption is required, and if so, which encryption algorithm to use and with what parameters; whether “reliable messaging” must be used, and if so, how long between transmission retries, etc. Other requirements may include role membership certificates a consumer must provide, and correspondingly, role membership certificates that the consumer is willing or able to provide; what type of authentication must be used; a minimum price a provider is willing to accept for a service, and a maximum price a consumer is willing to pay for a service.
In a typical Web services scenario, a business application sends a request to a service at a given URL using the Simple Object Access Protocol (SOAP) over HTTP. SOAP is a standard for XML-based information exchange between distributed applications. Although other transports are possible, SOAP is typically transmitted over HTTP providing a platform for communication with or between, web services. The service receives the request, processes it, and returns a response. An example of a web service is a stock quote service, in which a request asks for the current price of a specified stock, and a response provides the stock price. Another example could be a service that maps out an efficient route for the delivery of goods. In this case, a business sends a request containing the delivery destinations, which the service processes to determine an appropriate delivery route.
Providers and consumers of web services are frequently businesses, making web services predominantly business-to-business (B2B) transactions. A company or enterprise can be both a provider and a consumer of web services. For example, a wholesale distributor could be in the consumer role when it uses a web service to check on the availability of a product and in the provider role when it supplies prospective customers with different vendors' prices for the product.
In a web services architecture a service is an implementation of a service description and a service description is the metadata describing the service. A service description must include sufficient information for a service requestor to access the service it describes including its interface and location; resource discovery metadata such as classification may also be included.
Generally, a service provider publishes a service description to a service registry. A service requester then finds the service description via the service registry. The services description contains sufficient information for the service requester to bind to the service provider to use the service. Alternatively, a service request may have access to the service description via some other means, such as hard-coding, so that it can communicate directly to the service provider without accessing a service registry.
Several methods are currently available for services to publish descriptions of their requirements or offerings. For example, the Web Services Description Language (WSDL) has been developed for this purpose. WSDL describes a service as a set of ‘ports’ which group related interactions that are possible between the application (service requester) and the web service (service provider). Interactions to a service are described as ‘operations’ that may have an input message and optionally a resulting output message. Each operation describes a potential interaction with the web service. This may be a request from an application to the web service or a request from one service to another. Interactions in either direction can be one-way or can require a response. In other words, WSDL describes a service in terms of possible interactions with it. For example a digital library search service might offer a search interface with operations for keyword search (an input message may contain a simple text-based search string) and advanced search (input message contains a number of field-value pairs), in both cases the output message could contain a list of matching result descriptions.
The purpose of Universal Discovery, Description and Integration (UDDI) is to allow consumers to determine what web services are available. UDDI is a specification for distributed registries of web services. A UDDI web services registry is itself a web service that can be accessed via SOAP from an application or other service that wishes to discover web services. UDDI specifies interfaces for applications to publish web services (as WSDL documents) and to discover web services (via their WSDL documents). A UDDI entry actually contains more that just a WSDL interface and implementation, it can also include further metadata such as quality of service parameters, payment mechanisms, security and keywords for resource discovery.
There are generally two different uses for WSDL documents. During development of a web services consumer, the developer needs to know the interface to the service that the application will bind to. When the application is running it needs details of a specific implementation of that service so that it can bind to it. WSDL can be used to specify both interfaces and their implementations. A WSDL document provides information content of interactions with a web service but doesn't explain how to communicate that information between an application and a web service. For this purpose, WSDL allows a ‘binding’ to be specified. In practice, this is likely to be another XML-based standard, such as SOAP.
In the digital library example above, the service's WSDL description specifies that the search service offers a keyword search operation that takes a text string as its input message. SOAP allows an application to invoke this operation by sending a SOAP message to the service. SOAP specifies the format of the request and response documents, which are generally XML document sent over HTTP. However, currently there is a standard way of encoding WSDL messages in SOAP to achieve interoperability.
There are different ways to group requirements or offering options into sets. However, traditionally web services implementations do not define individual requirements or offerings themselves. There are also different ways to describe the individual requirements or offerings for particular types of web services or for particular aspects of communication between web service components. Additionally, languages like ebXML CPP/A exist that express complete descriptions of a specific set of service requirements and offerings, and that provide a manual process for matching the requirements of a consumer component against the offerings of a provider component.
Traditional web services architectures do not provide a standard way of describing enough of the semantics of individual requirements or offerings to allow automated matching of requirements or offerings. Nor do they provide an algorithm for automatically performing such matches. Additionally, none of the current “semantic web” based mechanisms support descriptions of the types of semantics needed to match typical web service requirements and offerings with web services consumers desires. For example, a consumer web service component may require the use of “DES encryption” or “IDEA encryption”, and a provider web service component may offer the use of either “DES encryption” or “AES encryption”.
Various semantic web languages such as the Web Ontology Language (OWL) and its derivatives have been proposed for expressing requirements (also known as policy constraints), since such languages can theoretically express the semantics of both policy vocabulary items and constraints on those items. However, none of the current semantic web languages support arithmetic comparison operators for comparing policy constraints. Additionally, since semantic web languages are required to specify far more, and more complex, semantics than a web service policy requires, developing the appropriate taxonomies and ontologies requires skill in semantic web concepts and languages that are not always readily available to web services developers.
Another potential approach for specifying policy constraints is the Object Constraint Language. This language has many of the types of predicate functions needed in a policy constraint language. However, OCL, is not an XML-based language, which is important for web services, and it is not designed to deal with intersection or union of predicate functions. Yet another approach is reflected by the OASIS Standard extensible Access Control Markup Language (XACML) profile for Web Services (also known as WSPL). WSPL provides facilities for defining or specifying both policy sets and policy constraints, but requires the same language syntax be used for defining both policy sets and policy constraints, thus preventing WSPL from interoperating with other policy set definition languages.
Another approach is the ebXML Collaboration-Protocol Profile and Agreement Specification (CPP/A). CPP/A includes one schema (CPP) for describing policies regarding a wide range of “collaboration protocols”, including data-transport, reliable messaging, signaling, security, packaging, and specific message exchanges, and another schema (CPA) that describes an agreed-upon set of collaboration protocol parameters. However, CPP/A has no general policy set or policy constraint mechanisms. Instead, all of the functionality uses vocabulary items that have implicit semantics. Thus CPP/A is unable to express constraints on arbitrary new vocabularies, and depends on users accepting the CPP/A vocabulary.
In general, with the exception of WSPL, traditional web-services policy techniques do not include the ability to specify, compare, or combine hierarchies among policy constraints and/or the individual requirement of a policy constraint. Additionally, traditional web-services policy techniques do not provide any ability to specify a preferred order for constraint values, or any other explicit choice mechanisms and only WSPL supports specifying preferred order for policy sets. Furthermore, traditional web-services policy techniques do not provide for policy constraints, requirements or offerings to be defined in a language separate from the language used to define the full policy. Thus, such techniques cannot incorporate policy constraints from policies defined using a different policy definition language without requiring the complete translation of the entire policy. Thus, there is no existing web services or policy definition language that satisfies the requirements of policy constraints.